A 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) is composed of an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a Mobility Management Entity (MME), a Serving Gateway (S-GW), a Packet Data Network Gateway (P-GW or PDN GW), a Home Subscriber Server (HSS), a 3GPP Authentication, Authorization and Accounting (AAA) server, a Policy and Charging Rules Function (PCRF) entity, and other supporting nodes.
FIG. 1 is a schematic diagram of a system architecture of an EPS in the related art. As shown in FIG. 1, the MME is responsible for related work of a control plane such as mobility management, non-access layer signaling processing, and user mobility management context management; the S-GW is an access gateway device connected to the E-UTRAN, forwards data between the E-UTRAN and the P-GW, and is responsible for caching paging waiting data; the P-GW is a border gateway of an EPS and a Packet Data Network (PDN), which is responsible for PDN access and data forwarding between the EPS and the PDN; and the PCRF is a policy and charging rules function entity, is connected to an operator Internet Protocol (IP) service network through a receiving interface Rx, and acquires service information. In addition, it is connected to a gateway device in the network through a Gx/Gxa/Gxc interface, and is responsible for initiating the establishment of an IP bearer, guaranteeing the Quality of Service (QoS) of service data, and performing charge control.
The EPS supports interworking with non-3GPP systems, where interworking with non-3GPP systems is implemented through S2a/b/c interfaces, and the P-GW serves as an anchor between the 3GPP and non-3GPP systems. In a system architecture diagram of the EPS, non-3GPP systems are divided into trusted non-3GPP IP access and untrusted non-3GPP IP access. The trusted non-3GPP IP access may be directly connected to the P-GW through the S2a interface (a trusted Access GateWay (AG or AGW) exists in the trusted non-3GPP access system, and the AGW and the P-GW are connected through the S2a interface); untrusted non-3GPP IP access requires a connection between an Evolved Packet Data Gateway (ePDG) and the P-GW, an interface between the ePDG and the P-GW is S2b, and S2c provides related control and mobility support of a user plane between a User Equipment (UE) and the P-GW, a supported mobility management protocol being Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6).
In the EPS system, a Policy and Charging Enforcement Function (PCEF) entity exists in the P-GW, and a Gx interface (see FIG. 1) between the PCRF and the P-GW exchanges information. When the interface between the P-GW and the S-GW is based on Proxy Mobile IPv6 (PMIPv6), the S-GW also has a Bearer Binding and Event Report Function (BBERF) entity to perform QoS control on an IP flow, and the S-GW and the PCRF exchange information through a Gxc interface (see FIG. 1). When a trusted non-3GPP access system accesses, the BBERF also resides in a trusted non-3GPP access gateway. The trusted non-3GPP access gateway exchanges information with the PCRF through a Gxa interface (see FIG. 1). When the UE roams, an S9 interface serves as an interface between a home PCRF and a visitor PCRF, and also provides an Application Function (AF) of the service for the UE. Service information for making a Policy and Charging Control (PCC) policy is sent to the PCRF through the Rx interface. In 3GPP, the corresponding PDN may be found through an Access Point Name (APN). One connection from the UE to the PDN network is usually referred to as an IP Connectivity Access Network (IP-CAN) session. During the setup of the IP-CAN session, the BBERF and the PCEF set up a Diameter session with the PCRF respectively, and through these Diameter sessions, policy and charging information for controlling the IP-CAN session and information for making a policy are transmitted.
The EPS supports a UE to simultaneously access one PDN through multiple access networks, namely Multiple Access. FIG. 2 is a schematic diagram of a multi-access scenario in the related art. As shown in FIG. 2, a UE is simultaneously covered by non-3GPP and 3GPP access to access a PDN through the same P-GW by means of a non-3GPP IP access network and a 3GPP IP access network.
FIG. 3 is a flowchart of setting up a Multiple Access IP-CAN session in the related art. As shown in FIG. 3, after a UE is within a dual coverage range of a 3GPP access network and a trusted non-3GPP access network, the UE establishes a connection to a default PDN through the 3GPP access network and the trusted non-3GPP access network simultaneously. The specific steps are described as follows.
In step S301, a UE sends an attach request message to an MME by carrying a Network Access Identifier (NAI), an APN, a network-based IP flow migration NBIFOM support, and an NBIFOM mode.
In step S302, the MME initiates an authentication flow for the UE, and authentication related information is exchanged between the MME and the HSS as needed. After the authentication succeeds, the MME initiates a location update flow, and an HSS sends subscription data of the UE to the MME. In the authentication process, the HSS sends P-GW selection information to the MME, including a default APN. The MME selects a P-GW according to the APN, and the MME selects an S-GW, the NBIFOM support, and the NBIFOM mode.
In step S303, the MME sends a create session request message to the S-GW, wherein a default bearer setup request message carries the NAI, the APN, an IP address of the selected P-GW, the NBIFOM support, and the NBIFOM mode.
In step S304, the S-GW sends a create session request message to the P-GW, wherein the request message carries the NAI, the APN, the NBIFOM support, and the NBIFOM mode.
In step S305, a PCEF residing on the P-GW sends an “IP-CAN session setup indication” message to a PCRF, wherein the “IP-CAN session setup indication” message carries the NAI, the APN, an IP address located by the P-GW to the UE, the NBIFOM support, and the NBIFOM mode. The PCRF acquires subscription information of the UE to make a policy decision, including whether to support the NBIFOM and the NBIFOM mode.
In step S306, the PCRF returns an “IP-CAN session setup confirmation” message to the P-GW, wherein the “IP-CAN session setup confirmation” message carries corresponding PCC rules and event triggers, as well as the NBIFOM support and the NBIFOM mode. The PCEF installs the PCC rules and the event triggers.
In step S307, the P-GW returns a create session response message to the S-GW, wherein the message carries the IP address allocated by the P-GW for the UE, the NBIFOM support, and the NBIFOM mode.
In step S308, the S-GW returns a create session confirmation message to the MME, wherein the confirmation message carries the IP address of the UE, the NBIFOM support, and the NBIFOM mode.
In step S309, the MME, the eNodeB, and the UE interact to establish a radio bearer, and the UE acquires the NBIFOM support and the NBIFOM mode.
In step S310, after the radio bearer is established, the MME sends an update bearer request to the S-GW to notify the eNodeB of address information and the like, and the S-GW returns a response message.
In step S311, the UE performs a specific non-3GPP access process and accesses a trusted non-3GPP access network.
In step S312, after accessing the trusted non-3GPP access network, the UE requests an HSS/AAA to perform EPS access authentication; after receiving the EPS access authentication request, the HSS/AAA authenticates the UE that sends the request; and after completing the authentication of the UE, the HSS/AAA sends, back to a trusted non-3GPP access gateway, the P-GW selected in the 3GPP access and the APN contracted by the UE, including the default APN.
In step S313, after the authentication is successful, a layer-3 attach flow is triggered, and a message sent from the UE to the trusted access gateway carries a handover indicator, the NBIFOM support, and an NBIFOM Default access.
In step S314, the trusted non-3GPP access gateway selects the same P-GW according to the handover indicator, and sends a create session request message to the P-GW, where the request message carries NAI, APN, handover indication, NBIFOM support, and NBIFOM. Default access;
Step S315, the PCEF resident in the P-GW sends an “IP-CAN session modification indication” message to the PCRF, wherein the “IP-CAN session modification indication” message carries NBIFOM support, NBIFOM default access;
In step S316, the PCRF makes a decision to confirm support of the NBIFOM and the NBIFOM default access. The PCRF returns an “IP-CAN session modification confirmation” message to the P-GW, wherein the “IP-CAN session modification confirmation” message carries the NBIFOM support and the NBIFOM default access.
In step S317, the P-GW saves its own IP address and other information to the HSS, and registers multiple accesses in the HSS.
In step S318, the P-GW is maintained to two tunnels of the S-GW and the trusted non-3GPP access gateway according to the NBIFOM support simultaneously; and the P-GW returns a create session request message to the trusted non-3GPP access gateway, wherein the message carries the IP address allocated by the P-GW for the UE, the NBIFOM support, and the NBIFOM default access.
In step S319, the trusted non-3GPP access gateway returns a response message to the UE, wherein the response message carries the IP address of the UE, the NBIFOM support, and the NBIFOM default access.
Through the above flow, the PCRF performs policy and charging control through IP-CAN sessions of 3GPP access and non-3GPP access simultaneously. The UE obtained the NBIFOM mode and default access.
In this scenario, the P-GW allocates an IP address for the UE, that is, there is only one IP-CAN session between the UE and the PDN. The P-GW or the PCRF determines an access network through which an IP data flow is sent to the UE according to different characteristics of the service. For example, when the non-3GPP access network is WiFi, the IP flows of Http and Ftp may access the network through the WiFi, and meanwhile, the IP flow of VoIP may be sent to the UE through 3GPP. In this way, services with lower real-time requirements, such as Http and Ftp, may take advantage of lower WiFi charges, while services with higher real-time requirements such as VoIP may take advantages of 3GPP QoS control and better mobility management.
If the NBIFOM mode determined by a negotiation between the UE and the network is a Network-initiated mode, a network-initiated flow migration mode will be supported. As shown in FIG. 4, FIG. 4 is a flowchart of a network-initiated flow migration in the related art. The specific steps are as follows.
In step S401, a PCRF determines to initiate a flow migration upon receiving a trigger. The trigger includes: receiving, by the PCRF, new service request information from an AF, making a PCC policy and determining an access network for new service transmission. Or, the PCRF needs to adjust an access network for the ongoing service transmission because of a network load, a contract change or a network policy change.
In step S402, the PCRF provides a message through a policy and charging rule to send a PCC rule 1 and an allowed access network type to a PCEF. The allowed access network type indicates that when the PCEF detects service data flows identified by the PCC rule 1, these service data flows are sent to an access network indicated by the allowed access network type. The PCC rule 1 carries a PCC rule identifier (i.e., PCC rule identifier 1) and a service data flow template, wherein one or more service data flow filters may be included.
In step S403, the PCEF installs the PCC rule 1 and associates the PCC rule 1 with the corresponding access network connection according to the allowed access network type. In addition, the PCEF extracts an NBIFOM routing rule 1 according to the received information. The NBIFOM routing rule 1 also includes information such as an NBIFOM routing rule identifier (i.e., routing rule identifier 1), a packet filter in the PCC rule 1, and the allowed access network type. If a service filter template in the PCC rule 1 includes multiple packet filters, the PCEF extracts multiple NBIFOM routing rules.
In step S404, the PCEF sends the NBIFOM routing rule 1 to the UE by using an existing flow.
In step S405, the PCEF returns a response message to the PCRF.
The conventional art also supports a flow for a UE to request a network to make or change a flow migration policy. FIG. 5 is a flowchart of a UE requesting IP flow mapping in the related art. As shown in FIG. 5, the method includes the following steps.
In step S501, a UE determines to initiate an IP flow mapping request flow upon receiving a trigger. The trigger may include: the UE may determine to initiate a new service and hope that the service will not be transmitted on a default access or the UE determines to change an access network for the ongoing service transmission because of a network load, a network policy, etc.
In step S502, the UE initiates an IP flow mapping request flow in the conventional art. A request message carries IP flow mapping information, and the information carries a packet filter, a requested access network type, and a requested operation type. The requested operation type includes addition (that is, adding a Packet filter), modification (that is, modifying an existing packet filter or modifying an allowed access network type) or deletion (that is, deleting an existing packet filter, i.e., deleting a certain NBIFOM routing rule).
In step S503, a P-GW extracts an NBIFOM routing rule2 according to the IP flow mapping information. The NBIFOM routing rule2 carries information in the IP flow mapping information. The P-GW may allocate a new routing rule identifier (routing rule identifier 2).
In step S504, a PCEF residing in the P-GW sends a policy and charging rule request message to a PCRF. The message carries the NBIFOM routing rule2 and an operation type of the NBIFOM routing rule2.
In step S505, the PCRF makes a policy decision. For the addition operation, the PCRF makes a new PCC rule (PCC rule 2). For the modification operation, the PCRF modifies the original PCC rule. In addition, the PCRF determines a corresponding allowed access network type according to a requested access network type. For the deletion operation, the PCRF Delete the original PCC rule.
In step S506, the PCRF returns a confirmation message. For the addition or modification operation, the message carries a newly-made PCC rule 2 or an updated PCC rule 1 and an allowed access network type.
In step S507, the PCEF extracts the NBIFOM routing rule according to the received information. If the operation is the addition operation, the PCEF makes a new NBIFOM routing rule according to the received information. If the operation is the modification operation, the PCEF updates the original NBIFOM routing rule according to the received information.
In step S508, the PCEF residing in the P-GW returns a response to the UE, carrying the NBIFOM routing rule. If it is the deletion operation, the PCEF only returns a response message and does not carry the NBIFOM routing rule.
In the flow shown in FIG. 4, the PCRF instructs an IP flow transmission access network through the made PCC rule and allow access type, and the PCEF extracts the NBIFOM routing rule according to the information received from the PCRF. In the flow shown in FIG. 5, the UE requests to modify the NBIFOM routing rule received from the network. The PCEF receives the request of the UE and sends a request to the PCRF to modify the NBIFOM routing rule. Then, there is no information about the NBIFOM routing rule before the PCRF. Thus, in fact, the PCRF does not know what information the PCRF modifies, so the PCRF cannot make a correct decision. As a result, the above flow cannot be performed.
To solve the problem in the related art that a PCRF is unable to modify a PCC rule, no effective solution has been proposed yet.